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Abstract 


This document analyzes common security threats to the Optimized Link 
State Routing Protocol version 2 (OLSRv2) and describes their 
potential impacts on Mobile Ad Hoc Network (MANET) operations. It 
also analyzes which of these security vulnerabilities can be 
mitigated when using the mandatory-to-implement security mechanisms 
for OLSRv2 and how the vulnerabilities are mitigated. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8116. 
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Les 


Introduction 


The Optimized Link State Routing Protocol version 2 (OLSRv2) 
[RFC7181] is a successor to OLSR [RFC3626] as a routing protocol for 
Mobile Ad Hoc Networks (MANETs).  OLSRv2 retains the same basic 
algorithms as its predecessor; however, it offers various 
improvements, e.g., a modular and flexible architecture allowing 
extensions (such as for security) to be developed as add-ons to the 
basic protocol. Such building blocks and modules include [RFC5148], 
[RFC5444], [RFC5497], [RFC6130], [RFC7182], [RFC7183], [RFC7187], 
[RFC7188], [RFC7466], etc. 


The developments reflected in OLSRv2 have been motivated by increased 
real-world deployment experiences, e.g., from networks such as 
FunkFeuer [FUNKFEUER], and the requirements to be addressed for 
continued successful operation of these networks. With participation 
in such networks increasing (the FunkFeuer community network has, 
e.g., roughly 400 individual participants at the time of publication 
of this document), operating under the assumption that participants 
can be "trusted" to behave in a non-destructive way, is naive. With 
deployment in the wider Internet, and a resultant increase in user 
numbers, an increase in attacks and abuses has followed necessitating 
a change in recommended practices. For example, SMTP servers, which 
were initially available for use by everyone on the Internet, require 
authentication and accounting for users today [RFC5068]. 


As OLSRv2 is often used in wireless environments, it is potentially 
exposed to different kinds of security threats, some of which are of 
greater significance when compared to wired networks. As radio 
Signals can be received as well as transmitted by any compatible 
wireless device within radio range, there are commonly no physical 
constraints on the conformation of nodes and communication links that 
make up the network (as could be expected for wired networks). 


A first step towards hardening against attacks disrupting the 
connectivity of a network is to understand the vulnerabilities of the 
routing protocol managing the connectivity. Therefore, this document 
analyzes OLSRv2 in order to understand its inherent vulnerabilities 
and resilience. The authors do not claim completeness of the 
analysis but hope that the identified attacks, as presented, form a 
meaningful starting point for developing and deploying increasingly 
well-secured OLSRv2 networks. 


This document describes security vulnerabilities of OLSRv2 when it is 
used without the mandatory-to-implement security mechanisms, as 
specified in Section 23.5 of [RFC7181]. It also analyzes which of 
these security vulnerabilities can be mitigated when using the 
mandatory-to-implement security mechanisms for OLSRv2 and how the 
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vulnerabilities are mitigated. This separation is important since, 
as explicitly stated in [RFC7181]: 


Any deployment of OLSRv2 SHOULD use the security mechanism 
specified in [RFC7183] but MAY use another mechanism if more 
appropriate in an OLSRv2 deployment. For example, for longer-term 
OLSRv2 deployments, alternative security mechanisms (e.g., 
rekeying) SHOULD be considered. 


Moreover, this document is also based on the assumption that no 
additional security mechanism such as IPsec is used in the IP layer, 
or other mechanisms on lower layers, as not all MANET deployments may 
be able to accommodate such common protection mechanisms (e.g., 
because of limited resources of MANET routers). 


As NHDP is a fundamental component of OLSRv2, the vulnerabilities of 
NHDP, discussed in [RFC7186], also apply to OLSRv2. 


It should be noted that many OLSRv2 implementations are configurable, 
and so an attack on the configuration system (such as [RFC7939] and 
[RFC7184]) can be used to adversely affect the operation of an OLSRv2 
implementation. 


1.1.  OLSRv2 Overview 


OLSRv2 contains three basic processes: neighborhood discovery, 
Multipoint Relay (MPR) selection, and Link State Advertisements 
(LSAs). They are described in the sections below with sufficient 
details to allow elaboration of the analyses in this document. 


1.1.1. Neighborhood Discovery 


Neighborhood discovery is the process whereby each router discovers 
the routers that are in direct communication range of itself (1-hop 
neighbors) and detects with which of these it can establish 
bidirectional communication. Each router sends HELLO messages 
periodically, listing the identifiers of all the routers from which 
it has recently received a HELLO message as well as the "status" of 
the link (heard or verified bidirectional). A router A receiving a 
HELLO message from a neighbor router B, in which B indicates it has 
recently received a HELLO message from A, considers the link A-B to 
be bidirectional. As B lists identifiers of all its neighbors in its 
HELLO message, A learns the "neighbors of its neighbors" (2-hop 
neighbors) through this process. HELLO messages are sent 
periodically; however, certain events may trigger non-periodic 
HELLOs.  OLSRv2 [RFC7181] uses NHDP [RFC6130] as its neighborhood 
discovery mechanism. The vulnerabilities of NHDP are analyzed in 
[RFC7186]. 
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1.1.2. MPR Selection 


Multipoint Relay (MPR) selection is the process whereby each router 
is able to identify a set of relays for efficiently conducting 
network-wide broadcasts. Each router designates, from among its 
bidirectional neighbors, a subset (the "MPR set") such that an 
OLSRv2-specific multicast message transmitted by the router and 
relayed by the MPR set can be received by all its 2-hop neighbors. 
MPR selection is encoded in outgoing NHDP HELLO messages. 


In their HELLO messages, routers may express their "willingness" to 
be selected as an MPR using an integer between 0 and 7 ("will never" 
to "will always"). This is taken into consideration for the MPR 
calculation and is useful, for example, when an OLSRv2 network is 
"planned". The set of routers having selected a given router as an 
MPR is the MPR selector set of that router. A study of the MPR 
flooding algorithm can be found in [MPR-FLOODING]. 


1.1.3. Link State Advertisement 


Link State Advertisement (LSA) is the process whereby routers 
determine which link state information to advertise through the 
network. Each router must advertise, at least, all links between 
itself and its MPR selectors in order to allow all routers to 
calculate shortest paths. Such LSAs are carried in Topology Control 
(IC) messages, which are broadcast through the network using the MPR 
flooding process described in Section 1.1.2. As a router selects 
MPRs only from among bidirectional neighbors, links advertised in TC 
are also bidirectional and routing paths calculated by OLSRv2 contain 
only bidirectional links.  TCs are sent periodically; however, 
certain events may trigger non-periodic TCs. 


1.2. Link State Vulnerability Taxonomy 
Proper functioning of OLSRv2 assumes that: 


o each router signals its presence in the network and the topology 
information that it obtained correctly; 


o each router can acquire and maintain a topology map that 
accurately reflects the effective network topology; and, 


o that the network converges, i.e., that all routers in the network 
will have sufficiently identical topology maps. 


An OLSRv2 network can be disrupted by breaking any of these 


assumptions, specifically that (a) routers may be prevented from 
acquiring a topology map of the network, (b) routers may acquire a 
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topology map that does not reflect the effective network topology, 
and (c) two or more routers may acquire inconsistent topology maps. 


1.3. OLSRv2 Attack Vectors 


Besides "radio jamming", attacks on OLSRv2 consist of a compromised 
OLSRv2 router injecting apparently correct, but invalid, control 
traffic (TCs, HELLOs) into the network. A compromised OLSRv2 router 
can either (a) advertise erroneous information about itself (its 
identification and its willingness to serve as an MPR), henceforth 
called identity spoofing, or (b) advertise erroneous information 
about its relationship to other routers (pretend existence of links 
to other routers), henceforth called link spoofing. Such attacks may 
disrupt the LSA process by targeting the MPR flooding mechanism or by 
causing incorrect link state information to be included in TCs, 
causing routers to have incomplete, inaccurate, or inconsistent 
topology maps. Ina different class of attacks, a compromised OLSRv2 
router injects control traffic designed so as to cause an in-router 
resource exhaustion, e.g., by causing the algorithms calculating 
routing tables or MPR sets to be invoked continuously, preventing the 
internal state of a router from converging, which depletes the energy 
of battery-driven routers, etc. 


2. Terminology 
This document uses the terminology and notation defined in [RFC5444], 


[RFC6130], and [RFC7181]. Additionally, it defines the following 
terminology: 


Compromised OLSRv2 router: An attacker that eavesdrops on the 
network traffic and/or generates syntactically correct OLSRv2 
control messages. Control messages emitted by a compromised 
OLSRv2 router may contain additional information or omit 
information, as compared to a control message generated by a non- 
compromised OLSRv2 router located in the same topological position 
in the network. 


Legitimate OLSRv2 router: An OLSRv2 router that is not a compromised 
OLSRv2 router. 


3. Topology Map Acquisition 


Topology Map Acquisition relates to the ability for any given router 
in the network to acquire a representation of the network 
connectivity. A router that is unable to acquire a topology map is 
incapable of calculating routing paths and participating in 
forwarding data. Topology map acquisition can be hindered by (i) TCs 
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not being delivered to (all) routers in the network, such as what 
happens in case of flooding disruption, or (ii) in case of "jamming" 
of the communication channel. 


The jamming and flooding disruption due to identity spoofing and link 
Spoofing have been discussed in [RFC7186]. 


3.1. Attack on Jittering 


OLSRv2 incorporates a jittering mechanism: a random, but bounded, 
delay on outgoing control traffic [RFC5148]. This may be necessary 
when link layers (such as 802.11 [IEEE802.11]) are used that do not 
guarantee collision-free delivery of frames and where jitter can 
reduce the probability of collisions of frames on lower layers. 


In OLSRv2, TC forwarding is jittered by a value between 0 and 

MAX JITTER. In order to reduce the number of transmissions, when a 
control message is due for transmission, OLSRv2 piggybacks all queued 
messages into a single transmission. Thus, if a compromised OLSRv2 
router sends many TCs within a very short time interval, the jitter 
time of the attacked router tends towards 0. This renders jittering 
ineffective and can lead to collisions on the link layer. 


In addition to causing more collisions, forwarding a TC with little 
or no jittering can make sure that the TC message forwarded by a 
compromised router arrives before the message forwarded by legitimate 
routers. The compromised router can thus inject malicious content in 
the TC: for example, if the message identification is spoofed, the 
legitimate message will be discarded as a duplicate message. This 
preemptive action is important for some of the attacks introduced in 
the following sections. 


3.2. Hop Count and Hop Limit Attacks 


The hop count and hop limit fields are the only parts of a TC that 

are modified when forwarding; therefore, they are not protected by 

integrity check mechanisms. A compromised OLSRv2 router can modify 
either of these when forwarding TCs. 


3.2.1. Modifying the Hop Limit 


A compromised OLSRv2 router can decrease the hop limit when 
forwarding a TC. This will reduce the scope of forwarding for the 
message and may lead to some routers in the network not receiving 
that TC. Note that this is not necessarily the same as not relaying 
the message (i.e., setting the hop limit to 0), as is illustrated in 
Figure 1. 


Clausen, et al. Informational [Page 8] 


RFC 8116 OLSRv2 Threats May 2017 


Figure 1: Hop Limit Attack 


A TC arrives at and is forwarded by router A such that it is received 
by both B and the malicious X. X can forward the TC without any 
delay (including without jitter) such that its transmissions arrive 
before that of B at C. Before forwarding, it significantly reduces 
the hop limit of the message. Router C receives the TC, processes 
(and forwards) it, and marks it as already received -- causing it to 
discard further copies received from B. Thus, if the TC is forwarded 
by C, it has a very low hop limit and will not reach the whole 
network. 


3.2.2. Modifying the Hop Count 


A compromised OLSRv2 router can modify the hop count when forwarding 
a TC. This may have two consequences: (i) if the hop count is set to 
the maximum value, then the TC will be forwarded no further or (ii) 
artificially manipulating the hop count may affect the validity time 
as calculated by recipients, when using distance-dependent validity 
times as defined in [RFC5497] (e.g., as part of a Fish Eye extension 
to OLSR2 [OLSR-FSR] [OLSR-FSR-Scaling]). 


v time(3hops)-9s v time(4hops)-12s v time (5hops)-15s 


Figure 2: Different Validity Times Based on the Distance in Hops 


In Figure 2, router A sends a TC with a validity time of 9 seconds 
for routers in a 3-hop distance, 12 seconds for routers in a 4-hop 
distance, and 15 seconds in a 5-hop distance. If X is a compromised 
OLSRv2 router and modifies the hop count (say, by decreasing it to 
3), then C will calculate the validity time of received information 
to 9 seconds -- after which it expires unless refreshed. If TCs from 
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A are sent less frequently than that up to 4 hops, this causes links 
advertised in such TCs to be only intermittently available to C. 


4. Effective Topology 


Link state protocols assume that each router can acquire an accurate 
topology map that reflects the effective network topology. This 
implies that the routing protocol is able to identify a path froma 
source to a destination, and this path is valid for forwarding data 
traffic. If an attacker disturbs the correct protocol behavior, the 
perceived topology map of a router can permanently differ from the 
effective topology. 


Consider the example in Figure 3(a), which illustrates the topology 
map as acquired by router S. This topology map indicates that the 
routing protocol has identified that for S, a path exists to D via B, 
which it therefore assumes can be used for transmitting data. If B 
does not forward data traffic from S, then the topology map in S does 
not accurately reflect the effective network topology. Rather, the 
effective network topology from the point of view of S would be as 
indicated in Figure 3(b): D is not part of the network reachable from 
router S. 


| s i-i s |----| 0 | 
nf NL m 


H , Nu , ` , ` , 


(a) (b) 
Figure 3: Incorrect Data Traffic Forwarding 


Some of the attacks related to NHDP, such as message timing attacks 
and indirect channel overloading, are discussed in [RFC7186]. Other 
threats specific to OLSRv2 are further detailed in this section. 


4.1. Incorrect Forwarding 


OLSRv2 routers exchange information using link-local transmissions 
(link-local multicast or limited broadcast) for their control 
messages, with the routing process in each router retransmitting 
received messages destined for network-wide diffusion. Thus, if the 
operating system in a router is not configured to enable forwarding, 
this will not affect the operating of the routing protocol or the 
topology map acquired by the routing protocol. It will, however, 
cause a discrepancy between the effective topology and the topology 
map, as indicated in Figures 3(a) and 3(b). 
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This situation is not hypothetical. A common error seen when 
deploying OLSRv2-based networks using a Linux-based computer as a 
router is to neglect enabling IP forwarding, which effectively 
becomes an accidental attack of this type. 


4.2. Wormholes 


A wormhole, depicted in the example in Figure 4, may be established 
between two collaborating devices that are connected by an out-of- 
band channel. These devices send traffic through the "tunnel" to 
their alter ego, which "replays" the traffic. Thus, routers D and S 
appear as if direct neighbors and are reachable from each other in 1 
hop through the tunnel, with the path through the MANET being 100 
hops long. 


| s |---- ....100-hop-long path ... po D | 
\ / 
\ / 
AX X 


1-hop path via wormhole 


Figure 4: Wormholing between Two Collaborating Devices Not 
Participating in the Routing Protocol 


The consequences of such a wormhole in the network depend on the 
detailed behavior of the wormhole. If the wormhole relays only 
control traffic, but not data traffic, the same considerations as in 
Section 4.1 apply. If, however, the wormhole relays all traffic 
(control and data alike), it is identical, connectivity wise, to a 
usable link - and the routing protocol will correctly generate a 
topology map reflecting the effective network topology. The 
efficiency of the topology obtained depends on (i) the wormhole 
characteristics, (ii) how the wormhole presents itself, and (iii) how 
paths are calculated. 


Assuming that paths are calculated with unit cost for all links, 
including the "link" presented by the wormhole, if the real 
characteristics of the wormhole are as if it were a path of more than 
100 hops (e.g., with respect to delay, bandwidth, etc.), then the 
presence of the wormhole results in a degradation in performance as 
compared to using the non-wormhole path. Conversely, if the "link" 
presented by the wormhole has better characteristics, the wormhole 
results in improved performance. 
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If paths are calculated using non-unit-costs for all links, and if 
the cost of the "link" presented by the wormhole correctly represents 
the actual cost (e.g., if the cost is established through 
measurements across the wormhole), then the wormhole may, in the 
worst case, cause no degradation in performance or, in the best case, 
improve performance by offering a better path. If the cost of the 
"link" presented by the wormhole is misrepresented, then the same 
considerations as for unit-cost links apply. 


An additional consideration with regard to wormholes is that they may 
present topologically attractive paths for the network; however, it 
may be undesirable to have data traffic transit such a path. An 
attacker could, by virtue of introducing a wormhole, acquire the 
ability to record and inspect transiting data traffic. 


4.3. Sequence Number Attacks 


OLSRv2 uses two different sequence numbers in TCs to (i) avoid 
processing and forwarding the same message more than once (Message 
Sequence Number) and to (ii) ensure that old information, arriving 
late due to, e.g., long paths or other delays, is not allowed to 
overwrite more recent information generated (Advertised Neighbor 
Sequence Number (ANSN)). 


4.3.1. Message Sequence Number 


An attack may consist of a compromised OLSRv2 router spoofing the 
identity of another router in the network and transmitting a large 
number of TCs, each with different Message Sequence Numbers. 
Subsequent TCs with the same sequence numbers, originating from the 
router whose identity was spoofed, would hence be ignored until 
eventually information concerning these "spoofed" TCs expires. 


4.3.2. Advertised Neighbor Sequence Number (ANSN) 


An attack may consist of a compromised OLSRv2 router spoofing the 
identity of another router in the network and transmitting a single 
TC with an ANSN significantly larger than that which was last used by 
the legitimate router. Routers will retain this larger ANSN as "the 
most recent information" and discard subsequent TCs with lower 
sequence numbers as being "old". 
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4.4. Indirect Jamming 


Indirect jamming is an attack in which a compromised OLSRv2 router 
is, by its actions, causing legitimate routers to generate inordinate 
amounts of control traffic, thereby increasing both channel 
occupation and the overhead incurred in each router for processing 
this control traffic. This control traffic will be originated from 
legitimate routers; thus, to the wider network, the malicious device 
may remain undetected. 


The general mechanism whereby a malicious router can cause indirect 
jamming is for it to participate in the protocol by generating 
plausible control traffic and to tune this control traffic to in turn 
trigger receiving routers to generate additional traffic. For 
OLSRv2, such an indirect attack can be directed at the neighborhood 
discovery mechanism and the LSA mechanism, respectively. 


One efficient indirect jamming attack in OLSRv2 is to target control 
traffic destined for network-wide diffusion. This is illustrated in 
Figure 5. 


The malicious router X selects router A as an MPR at time t0 in a 
HELLO. This causes X to appear as MPR selector for A and, 
consequently, A sets X to be advertised in its "Neighbor Set" and 
increments the associated "Advertised Neighbor Sequence Number" 
(ANSN). Router A must then advertise the link between itself and X 
in subsequent outgoing TCs (t1), also including the ANSN in such TCs. 
Upon X having received this TC, it declares the link between itself 
and A as no longer valid (t2) in a HELLO (indicating the link to A as 
LOST). Since only symmetric links are advertised by OLSRv2 routers, 
A will (upon receipt hereof) remove X from the set of advertised 
neighbors and increment the ANSN. Router A will then, in subsequent 
TCs, advertise the remaining set of advertised neighbors (i.e., with 
X removed) and the corresponding ANSN (t3). Upon X having received 
this information in another TC from A, it may repeat this cycle, 
alternating advertising the link A-X as "LOST" and as "MPR". 
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broadcast TC ANS={ } TC: () 
(X-A) ANSN ANSN++ ANSN 
| a | | a | | a | | a | 
fF oll—t AB RO d FII | ee d 
| | | | 
| select | | indicate | 
| as MPR | |as LOST | 
| x | | x | | x | | x | 
| payers À : io Ee j T E e EC EEN d 
to t1 t2 t3 


Description: The malicious X flips between link status MPR and LOST. 
Figure 5: Indirect Jamming in Link State Advertisement 


Routers receiving a TC message will parse and process this message, 
specifically updating their topology map as a consequence of 
successful receipt. If the ANSN between two successive TCs from the 
same router has incremented, then the topology has changed and 
routing sets are to be recalculated. This has the potential to be a 
computationally costly operation. 


A compromised OLSRv2 router may chose to conduct this attack against 
all its neighbors, thus maximizing its disruptive impact on the 
network with relatively little overhead of its own: other than 
participating in the neighborhood discovery procedure, the 
compromised OLSRv2 router will monitor TCs generated by its neighbors 
and alternate the advertised status for each such neighbor between 
"MPR" and "LOST". The compromised OLSRv2 router will indicate its 
willingness to be selected as an MPR as 0 (thus avoiding selection as 
an MPR) and may ignore all other protocol operations while still 
remaining effective as an attacker. 


The basic operation of OLSRv2 employs periodic message emissions, and 
by this attack it can be ensured that each such periodic message will 
entail routing table recalculation in all routers in the network. 


If the routers in the network have "triggered TCs" enabled, this 
attack may also cause an increased TC frequency.  Triggered TCs are 
intended to allow a (stable) network to have relatively low TC 
emission frequencies yet still allow link breakage or link emergence 
to be advertised through the network rapidly. A minimum message 
interval (typically much smaller than the regular periodic message 
interval) is imposed to rate-limit worst-case message emissions. 
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This attack can cause the TC interval to permanently become equal to 
the minimum message interval. [RFC7181] proposes as default that the 
minimum TC interval be 0.25 x TC_INTERVAL (TC_INTERVAL being the 
maximum interval between two TC messages from the same OLSRv2 
router). 


Indirect jamming by a compromised OLSRv2 router can thus have two 
effects: (i) it may cause increased frequency of TC generation and 
transmission, and (ii) it will cause additional routing table 
recalculation in all routers in the network. 


5. Inconsistent Topology 


Inconsistent topology maps can occur by a compromised OLSRv2 router 
employing either identity spoofing or link spoofing for conducting an 
attack against an OLSRv2 network. The threats related to NHDP, such 
as identity spoofing in NHDP, link spoofing in NHDP, and creating 
loops, have been illustrated in [RFC7186]. This section mainly 
addresses the vulnerabilities in [RFC7181]. 


5.1. Identity Spoofing 


Identity spoofing can be employed by a compromised OLSRv2 router via 
the neighborhood discovery process and via the LSA process. Either 
of them causes inconsistent topology maps in routers in the network. 
The creation of inconsistent topology maps due to neighborhood 
discovery has been discussed in [RFC7186]. For OLSRv2, the attack on 
the LSA process can also cause inconsistent topology maps. 


An inconsistent topology map may occur when the compromised OLSRv2 
router takes part in the LSA process by selecting a neighbor as an 
MPR, which in turn advertises the spoofed identities of the 
compromised OLSRv2 router. This attack will alter the topology maps 
of all routers of the network. 
As SS Be eer D en, eg SS X 
(X spoofs A) 


Description: A compromised OLSRv2 router X spoofs the identity of A, 
leading to a wrongly perceived topology. 


Figure 6: Identity Spoofing 
In Figure 6, router X spoofs the address of router A. If X selects F 


as an MPR, all routers in the network will be informed about the link 
F-A by the TCs originating from F. Assuming that (the real) A 
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selects B as an MPR, the link B-A will also be advertised in the 
network. 


When calculating paths, B and C will calculate paths to A via B, as 


illustrated in Figure 7(a); for these routers, the shortest path to A 
is via B. E and F will calculate paths to A via F, as illustrated in 
Figure 7(b); for these routers, the shortest path to A is via the 


compromised OLSRv2 router X, and these are thus disconnected from the 
real A. D will have a choice, as the path calculated to A via B is 
of the same length as the path via the compromised OLSRv2 router X, 
as illustrated in Figure 7(c). 


In general, the following observations can be made: 


o The network will be split in two, with those routers closer to B 
than to X reaching A, whereas those routers closer to X than to B 
will be unable to reach A. 


o Routers beyond B, i.e., routers beyond 1 hop away from A, will be 
unable to detect this identity spoofing. 


The identity spoofing attack via the LSA procedure has a higher 
impact than the attack on the neighborhood discovery procedure since 
it alters the topology maps of all routers in the network and not 
only in the 2-hop neighborhood. However, the attack is easier to 
detect by other routers in the network. Since the compromised OLSRv2 
router is advertised in the whole network, routers whose identities 
are spoofed by the compromised OLSRv2 router can detect the attack. 
For example, when A receives a TC from F advertising the link F-A, it 
can deduce that some entity is injecting incorrect link state 
information as it does not have F as one of its direct neighbors. 


(X spoofs A) 


A < ---- B < ---- C E ----» F ----» X 


(a) Routers B and C (b) Routers E and F 


A < --- B < --- C < --- D ---> E ---> F ----> X 
(X spoofs A) 
Description: These paths appear as calculated by the different 
routers in the network in presence of a compromised OLSRv2 router X, 


spoofing the address of A. 


Figure 7: Routing Paths towards A 
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As the compromised OLSRv2 router X does not itself send the TCs, but 
rather, by virtue of MPR selection, ensures that the addresses it 
spoofs are advertised in TCs from its MPR selector F, the attack may 
be difficult to counter. Simply ignoring TCs that originate from F 
may also suppress the link state information for other, legitimate, 
MPR selectors of F. 


Thus, identity spoofing by a compromised OLSRv2 router, participating 
in the LSA process by selecting MPRs only, creates a situation 
wherein two or more routers have substantially inconsistent topology 
maps: traffic for an identified destination is, depending on where in 
the network it appears, delivered to different routers. 


5.2. Link Spoofing 


Link spoofing is a situation in which a router advertises non- 
existing links to another router (possibly not present in the 


network). Essentially, TCs and HELLOs both advertise links to direct 
neighbor routers with the difference being the scope of the 
advertisement. Thus, link spoofing consists of a compromised OLSRv2 


router reporting that it has neighbors routers that are either not 
present in the network or are effectively not neighbors of the 
compromised OLSRv2 router. 


It can be noted that a situation similar to link spoofing may occur 
temporarily in an OLSR or OLSRv2 network without compromised OLSRv2 
routers: if A was, but is no more, a neighbor of B, then A may still 
be advertising a link to B for the duration of the time it takes for 
the neighborhood discovery process to determine this changed 
neighborhood. 


In the context of this document, link spoofing refers to a persistent 
situation where a compromised OLSRv2 router intentionally advertises 
links to other routers for which it is not a direct neighbor. 
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5.2.1. Inconsistent Topology Maps Due to Link State Advertisements 


Figure 8 illustrates a network in which the compromised OLSRv2 router 
X spoofs links to an existing router A by participating in the LSA 
process and including this non-existing link in its advertisements. 


A --- B --- C --- D --- E --- F --- G --- H --- X 
(X spoofs the link to A) 


Description: The compromised OLSRv2 router X advertises a spoofed 
link to A in its TCs; thus, all routers will record both of the links 
X-A and B-A. 


Figure 8: Link Spoofing 


As TCs are flooded through the network, all routers will receive and 
record information describing a link X-A in this link state 
information. If A has selected router B as an MPR, B will likewise 
flood this link state information through the network; thus, all 
routers will receive and record information describing a link B-A. 


When calculating routing paths, B, C, and D will calculate paths to A 
via B, as illustrated in Figure 9(a); for these routers, the shortest 
path to A is via B. F and G will calculate paths to A via X, as 
illustrated in Figure 9(b); for these routers, the shortest path to A 
is via X, and these are thus disconnected from the real router A. E 
will have a choice: the path calculated to A via B is of the same 
length as the path via X, as illustrated in Figure 9(b). 


A < --- B < --- C < --- D F ---> G ---> X ---> A 
(a) Routers B, C, and D (b) Routers F and G 
A < --- B < --- C < --- D < --- E ---> F ---> G ---> X ---> A 


(c) Router E 
Description: These paths appear as calculated by the different 
routers in the network in the presence of a compromised OLSRv2 router 


X, spoofing a link to router A. 


Figure 9: Routing Paths towards Router A 
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In general, the following observations can be made: 


o The network will be separated in two: routers closer to B than X 
will reach A, whereas routers closer to X than B will be unable to 
reach A. 


o Routers beyond B, i.e., routers beyond 1 hop away from A, will be 
unable to detect this link spoofing. 


6. Mitigation of Security Vulnerabilities for OLSRv2 


As described in Section 1, [RFC7183] specifies a security mechanism 
for OLSRv2 that is mandatory to implement. However, deployments may 
choose to use different security mechanisms if more appropriate. 
Therefore, it is important to understand both the inherent resilience 
of OLSRv2 against security vulnerabilities when not using the 
mechanisms specified in [RFC7183] and the protection that [RFC7183] 
provides when used in a deployment. 


6.1. Inherent OLSRv2 Resilience 


OLSRv2 (even when used without the mandatory-to-implement security 
mechanisms in [RFC7183]) provides some inherent resilience against 
part of the attacks described in this document. In particular, it 
provides the following resilience: 


o Sequence numbers: OLSRv2 employs message sequence numbers, which 
are specific per the router identity and message type. Routers 
keep an "information freshness" number (ANSN) incremented each 


time the content of an LSA from a router changes. This allows 
rejecting both "old" information and duplicate messages, and it 
provides some protection against "message replay". However, this 


also presents an attack vector (Section 4.3). 


o Ignoring unidirectional links: The neighborhood discovery process 
detects and admits only bidirectional links for use in MPR 
selection and LSA. Jamming attacks may affect only reception of 
control traffic; however, OLSRv2 will correctly recognize, and 
ignore, such a link that is not bidirectional. 


o Message interval bounds: The frequency of control messages, with 


minimum intervals imposed for HELLO and TCs. This may limit the 
impact from an indirect jamming attack (Section 4.4). 
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o Additional reasons for rejecting control messages: The OLSRv2 
specification includes a list of reasons for which an incoming 
control message should be rejected as malformed -- and allows that 
a protocol extension may recognize additional reasons for OLSRv2 
to consider a message malformed. Together with the flexible 
message format [RFC5444], this allows addition of security 
mechanisms, such as digital signatures, while remaining compliant 
with the OLSRv2 standard specification. 


6.2. Resilience by Using RFC 7183 with OLSRv2 


[RFC7183] specifies mechanisms for integrity and replay protection 
for NHDP and OLSRv2 using the generalized packet/message format 
described in [RFC5444] and the TLV definitions in [RFC7182]. The 
specification describes how to add an Integrity Check Value (ICV) in 
a TLV to each control message, providing integrity protection of the 
content of the message using Hashed Message Authentication Code 
(HMAC) / SHA-256. In addition, a timestamp TLV is added to the 
message prior to creating the ICV, enabling replay protection of 
messages. The document specifies how to sign outgoing messages and 
how to verify incoming messages, as well as under which circumstances 
an invalid message is rejected. Because of the HMAC/SHA-256 ICV, a 
shared key between all routers in the MANET is assumed. A router 
without valid credentials is not able to create an ICV that can be 
correctly verified by other routers in the MANET; therefore, such an 
incorrectly signed message will be rejected by other MANET routers, 
and the router cannot participate in the OLSRv2 routing process 
(i.e., the malicious router will be ignored by other legitimate 
routers). [RFC7183] does not address the case where a router with 
valid credentials has been compromised. Such a compromised router 
will not be excluded from the routing process, and other means of 
detecting such a router are necessary if required in a deployment: 
for example, using an asymmetric key extension to [RFC7182] that 
allows revocation of the access of one particular router. 


In the following sections, each of the vulnerabilities described 
earlier in this document will be evaluated in terms of whether OLSRv2 
with the mechanisms in [RFC7183] provides sufficient protection 
against the attack. It is implicitly assumed in each of the 
following sections that [RFC7183] is used with OLSRv2. 
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6. 


vei. 


2 


ls 


Topology Map Acquisition 


Attack on Jittering: As only OLSRv2 routers with valid credentials 


can participate in the routing process, a malicious router cannot 
reduce the jitter time of an attacked router to 0 by sending many 
TC messages in a short time. The attacked router would reject all 
the incoming messages as "invalid" and not forward them. The same 
applies for the case where a malicious router wants to assure that 
by forcing a 0 jitter interval, the message arrives before the 
same message forwarded by legitimate routers. 


Modifying the Hop Limit and the Hop Count: As the hop limit and hop 


oes 


count are not protected by [RFC7183] (since they are mutable 
fields that change at every hop), this attack is still feasible. 
It is possible to apply [RFC5444] packet-level protection by using 
ICV Packet TLV defined in [RFC7182] to provide hop-by-hop 
integrity protection -- at the expense of a requirement of 
pairwise trust between all neighbor routers. 


Effective Topology 


Incorrect Forwarding: As only OLSRv2 routers with valid credentials 


can participate in the routing process, a malicious router will 
not be part of the topology of other legitimate OLSRv2 routers. 
Therefore, no data traffic will be sent to the malicious router 
for forwarding. 


Wormholes: Since a wormhole consists of at least two devices 


forwarding (unmodified) traffic, this attack is still feasible and 
undetectable by the OLSRv2 routing process since the attack does 
not involve the OLSRv2 protocol itself (but rather lower layers). 
By using [RFC7183], it can at least be assured that the content of 
the control messages is not modified while being forwarded via the 
wormhole. Moreover, the timestamp TLV assures that the forwarding 
can only be done in a short time window after the actual TC 
message has been sent. 


Message Sequence Number: As the message sequence number is included 


in the ICV calculation, OLSRv2 is protected against this attack. 


Advertised Neighbor Sequence Number (ANSN): As the ANSN is included 


in the ICV calculation, OLSRv2 is protected against this attack. 


Indirect Jamming: Since the control messages of a malicious router 


will be rejected by other legitimate OLSRv2 routers in the MANET, 
this attack is mitigated. 
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6.2.3. Inconsistent Topology 


Identity Spoofing: Since the control messages of a malicious router 
will be rejected by other legitimate OLSRv2 routers in the MANET, 
a router without valid credentials may spoof its identity (e.g., 
IP source address or message originator address), but the messages 
will be ignored by other routers. As the mandatory mechanism in 
[RFC7183] uses shared keys amongst all MANET routers, a single 
compromised router may spoof its identity and cause harm to the 
network stability. Removing this one malicious router, once 
detected, implies rekeying all other routers in the MANET. 
Asymmetric keys, particularly when using identity-based signatures 
(such as those specified in [RFC7859]), may give the possibility 
of revoking single routers and verifying their identity based on 
the ICV itself. 


Link Spoofing: Similar to identity spoofing, a malicious router 
without valid credentials may spoof links, but its control 
messages will be rejected by other routers, thereby mitigating the 
attack. 


Inconsistent Topology Maps Due to LSAs: The same considerations for 
link spoofing apply. 


6.3. Correct Deployment 


Other than implementing OLSRv2, including appropriate security 
mechanisms, the way in which the protocol is deployed is also 
important to ensure proper functioning and threat mitigation. For 
example, Section 4.1 discussed considerations due to an incorrect 
forwarding-policy setting, and Section 4.2 discussed considerations 
for when intentional wormholes are present in a deployment. 


7. Security Considerations 


This document does not specify a protocol or a procedure but reflects 
on security considerations for OLSRv2 and for its constituent parts, 
including NHDP. The document initially analyses threats to topology 
map acquisition, with the assumption that no security mechanism 
(including the mandatory-to-implement mechanisms from [RFC7182] and 
[RFC7183]) is in use. Then, it proceeds to discuss how the use of 
[RFC7182] and [RFC7183] mitigate the identified threats. When 
[RFC7183] is used with routers using a single shared key, the 
protection offered is not effective if a compromised router has valid 
credentials. 
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